NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part2/11480

Internet Message Format | 1996-08-05 | 3.0 KB

Path: mail2news.demon.co.uk!genesis.demon.co.uk
From: Lawrence Kirby <[e-mail]>
Newsgroups: comp.lang.c
Subject: Re: Borland C's tmpnam()
Date: Sun, 24 Mar 96 13:18:15 GMT
Organization: none
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
X-NNTP-Posting-Host: genesis.demon.co.uk
X-Newsreader: Demon Internet Simple News v1.27
X-Mail2News-Path: genesis.demon.co.uk

In article <[e-mail]> [e-mail] "Larry Weiss" writes:

>> "The tempnam function generates a string that is a valid file name and that
>>  is not the name of an existing file."
>>
>
>I might have written the Standard to say "not the name of an existing file at
>the time that the name was created".

I don't think that is necessary. IMHO "an existing file" can only refer to
one that exists at the time, it cannot refer to something that may exist in
the future. To put it another way if a file with that name does not exist
until sometime later it is not "an existing file".

>  There is no guarantee that that
> particular
>name is somehow reserved against future use by other processes that may be
> competing
>with your C based process for file names.   Or am I wrong?
>  (in other words if
>your process doesn't hurry to open a file with that name, then all bets are off
>about that name already being used to represent an existing file).

Right - I see nothing that forbids this race condition since all guarantees
are based on whether the file exists or not. So it appears that tmpnam()
alone is unsafe in a pre-emptive environment. Because of:

"The tmpnam function generates a different string each time it is called,
 up to TMP_MAX times."

you have some guarantees about calling tmpnam() more than once in a
single program invocation. However one program invocation can only affect the
operation of another in a well-defined manner by altering its environment in
a globally visible way, which pretty much comes down to file operations.
Even those needn't be globally visible. Nevertheless it appears you can
change a file under a program's feet and still have well-defined behaviour (*),
as long as you don't try to open it more than once at the same time.

I suppose the question ultimately is whether you can create any sort
of syncronisation between concurrent program invocations using standard C.
The remove() function could be a possible starting point. If a file exists
and 2 programs race to remove() it, is exactly one of them guaranteed to
succeed (assuming remove() is a valid action on that file by those
programs)? I don't think so.

* - if you can't perform any form of synchronisation in standard C then
even this is not strictly true.

--
-----------------------------------------
Lawrence Kirby | [e-mail]
Wilts, England | [e-mail]
-----------------------------------------